Facilitating access to information stored on a network using an extended network universal resource locator

ABSTRACT

Systems and methods for facilitating access to stored information associated with a user, where a service provider receives, from a network entity controlling access to the stored information, a first message component encrypted with a first crypto-key associated with the network entity that can be decrypted by the network entity and a network address associated with the stored information. The service provider then receives a request for information enabling access to the stored information from an access portal associated with the user. Next, the service provider generates a response that includes the network address and the first message component and transmits the response to the access portal. The generated response is extensible by the access portal to include a second message component. The second message component is encrypted with a second crypto-key associated with the access portal. The extended response is usable to obtain access to the stored information.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of pending U.S. application Ser. No.11/139,512, filed May 31, 2005, entitled “Accessing Information On ANetwork Using An Extended Network Universal Resource Locator,” which isa continuation of U.S. application Ser. No. 09/471,490, filed Dec. 23,1999, entitled “Securing Electronic Transactions Over Public Networks”(which issued as U.S. Pat. No. 6,948,063 on Sep. 20, 2005), thedisclosures of which are incorporated by reference herein in theirentirety.

TECHNICAL FIELD

The present invention relates generally to electronic commerce and moreparticularly to securing electronic transactions made over publicnetworks such as the Internet.

BACKGROUND ART

The Internet has had a profound affect on various aspects of everydaycommerce. More and more individuals are utilizing the Internet toelectronically perform tasks which were previously performed in otherways. For example, electronic transactions are now commonplace on theInternet. Such transactions include electronic banking, electronic billpresentment, electronic bill payment and electronic purchasing.

As the use of the Internet for electronic commerce has developed, amodel has emerged in which users often access other entities on theInternet through a trusted entity such as a financial institute. Theseentities through which access to other entities is made will hereinafterbe referred to as “portals”.

The portals are often supported by a service provider. The serviceprovider, for example, may process electronic user requests, which arereceived by the portal, for information relating to a user's depositaccount at a particular bank by electronically accessing informationmaintained by the applicable bank and processing that information sothat it can be presented to the requesting user in a user friendly form.

Similarly, the service provider may also be the entity which responds touser requests received by the portal for billing information. Forexample, the service provider may receive summary bill information fromnumerous billers for numerous users and process this information suchthat the appropriate information can be presented in a user friendlymanner in response to a request for bill information submitted by theuser to the portal. However, if the user desires more detailed billinginformation, it is often preferable for the detailed bill information tobe provided to the requesting user directly by the biller rather than bythe service provider through the access portal.

Security of network communications relates to various aspects ofprotection. These include (i) secrecy, i.e. can someone other than theintended party view the data in transit?, (ii) immutability, i.e. howcan one be assured that someone has not altered the data in transit?,(iii) authentication, i.e. how can one ensure that each party in theconversation, e.g. session, is who it says it is?, (iv) authorization,i.e. is the authenticated party allowed to do what it is requesting todo?, and (v) non-repudiation, i.e. can a party repudiate itsinvolvement, e.g. its actions?.

Secrecy is generally provided by encrypting data. For example, encryptedHTML, i.e. HTML/HTTPS (SSL), is used to insure that unintended partiescan not see the information as it travels across the network, e.g. theInternet. However, this does not prevent the various transit points,e.g. the service provider and the portal, from viewing data that travelsover the network. Thus, for example, a URL to a payor's detailed billinformation could be misappropriated at a transit point or from thepayor's terminal, e.g. from the payor's browser history, and could thenlater be used to access the payor's detailed bill information.

Like secrecy, immutability is also generally provided by encrypting thedata. Typically, due to the nature of the algorithms, encryption whichprovides good secrecy also provides good immutability. For example,HTML/HTTPS is used to insure immutability as the data bits are travelingacross the network. That is, even if one were to improperly access dataoff a network router, or at a transit point, it would be virtuallyimpossible to read the misappropriated data; however, the data stillcould be altered. Thus, for example, an account number associated withthe payor's detailed bill information could be misappropriated at atransit point and mangled. It this were to occur, the biller would haveno way of confirming that a payor account number, originally sent by theportal to the payor and then sent by the payor to the biller with therequest for detailed bill information, has not been misappropriated andmangled before being received by the biller.

FIG. 1 is a somewhat simplified network diagram indicating variouschannels which may be established between network entities to provideelectronic bill presentment services. As shown in FIG. 1, the networkincludes users A-C which are represented on a network by network devices105A-105C. The network devices 105A-105C could, for example be anydevice capable of communicating over the network, such as a personalcomputer, palm computer, set top box etc. Billers A-C are alsorepresented on the network by network devices 110A-110C, typicallyalthough not necessarily high power workstations, mini-computers ormainframe computers, often referred to as servers. The network alsoincludes an access portal 115 and a service provider 120.

Users A-C access services available on the network by establishingchannels 125A-125C with the access portal 115. The access portal islinked to the service provider 120 by channel 130. The service providerin turn is linked to the billers A-C by channels 135A-135C.

For example, the channels 125A-125C may be Internet channels which areestablished through an Internet access provider, such as America Online(not shown), using a browser, such as browsers currently available fromMicrosoft Corporation and Netscape Corporation. Accordingly, thecommunications between the user devices 105A-105C and the access portal115 are typically encrypted HTML communication, i.e. HTML/HTTPS.

Communications between the access portal 115 and the service provider120 typically will follow a protocol such as IFX, or OFX etc., which maybetter ensure the security of the communications whether the link is viaa private network or a public network such as the Internet. Similarly,communications between the service provider 120 and the biller networkdevices 110A-110C will also typically follow an established protocol andbe transmitted via channels 135A-135C which are provided on a private orpublic network.

If detailed bill information is desired by a user, furthercommunications channels must be established between the requesting userand the appropriate biller. Accordingly, if user A desires detailedbilling information relating to the bills of billers A-C communicationlinks 140A-140C will be required as shown in FIG. 1. These communicationlinks will typically be established via the Internet using an Internetbrowser and accordingly carry encrypted HTML communications. It will berecognized that channels similar to channels 140A-140C could beestablished between user devices 105B and 105C and biller devices110A-110C to communicate detailed bill information from billers A-C tousers B and C.

Each of the users A-C will typically be known to different networkentities by different identifiers. For example, as shown in FIG. 2, eachof the users A-C are known to each of the billers A-C by the user'sname, e.g. A, B or C, the applicable user's address, e.g. ZA, ZB or ZC,and a unique account number, e.g. AA-CC which each biller associateswith each user.

The access portal 115 will typically know each of the users A-C by aunique user name, e.g. A′-C′ and a unique password, e.g. PA-PC.Alternatively, users may be known to the access portal 115 by a digitalcertificate, e.g. a digital signature, although this is relativelyuncommon today.

The user name and password or digital certificate are often referred toas the user's credentials and are used by the access portal 115 toauthenticate the user. The access portal 115 then vouches forauthenticated users to other network entities. Should a particular useralso have a transactional relationship with the access portal, forexample if the access portal is a user's financial institute or stockbrokerage firm, the user will also typically be known to the accessportal by additional information similar to that shown in the billercolumns of FIG. 2.

FIG. 3A depicts typical communications between and functions of variousnetwork entities in providing bill summary information to a requestinguser. As shown, network device 105A, representing user A, implements abrowser 305, typically stored on a local memory, to communicate itscredentials via an encrypted HTML communication over the Internetchannel 125A to the access portal 115. The access portal 115 processesthe credentials to authenticate user A, as indicated by referencenumeral 310. Portal 115 then provides a response, as represented by thecommunicated authentication message, to network device 105A eithergranting or denying access based on whether or not user A has beensuccessfully authenticated by the processing of the credentials. Ifaccess is granted, user A, operating network device 105A, may nowrequest bill summary information from the access portal 115 via thechannel 125A.

Having authenticated user A, the access portal 115 transmits the requestfor bill summary information via a protocol over channel 130 to theservice provider 120. In response to the request, the service provider120 retrieves the bill summary information and applicable universalresource locators (URL's) 315 from, for example, a local memory. Thebill summary information and URL's 315 are typically provided by thebillers via protocol or batch transmissions over channels 135A-135C tothe server 120 off-line, i.e. in non-real time, with respect to the userrequest for the bill summary information.

The bill summary information and URL's are provided over channel 130from the service provider 120 to the access portal 115. The accessportal 115 then directs the bill summary and associated URL's to theuser Internet device 105A via the Internet channel 125A in an encryptedHTML message.

Accordingly, bill summary information and URL's flow via a protocol fromthe biller to the service provider and from the service provider to theaccess portal. The bill summary information is only provided by theaccess portal to the user after authentication of the user. Further, thebill summary information and associated URL's for a particular user areprovided to the access portal for transmission to the requesting useronly if the access portal can vouch for the user to the service providerbased upon its authentication of the user.

The URL's associated with the bill summary information represent theaddresses to the bill detail information stored on the network 100 forthe transmitted summarized bill information. The bill detail informationof billers A-C may be respectively stored, for example, on the memories320A-320C. It should be recognized that, as described in theabove-referenced related applications, the bill detail information couldalso or alternatively be stored at the service provider 120 or atanother network site controlled, for example, by a bill aggregator. Inany event, the URL's to the bill detail information are passed, alongwith the bill summary information, from the service provider 120 to theaccess portal 115 and from there to the user network device 105A.Typically each URL is embedded as a hyperlink in the applicable billsummary information presentation which will appear on a display includedin the network device 105A.

A typical display is shown in FIG. 4. FIG. 4 depicts a display 400 ofnetwork device 105A which is used to present the requested bill summaryinformation for user A. As shown, the presentation includes the names ofbillers A-C in display areas 405A-405C, the applicable bill amountsXA-XC billed by each of the billers A-C to user A in display areas410A-410C, and a view bill request area associated with each of thebillers A-C in display areas 415A-415C which can be clicked on using amouse or other input device to activate the applicable hyperlink URLHA-HC, identified with reference numerals 420A-420C, to establish a linkto the bill detail information underlying the bill summary informationbeing presented. The applicable bill may also be paid directly from thebill summary presentation by clicking on the appropriate pay bill area425A-425C.

As shown in FIG. 3B, by clicking on view bill area 415A and therebyactivating the URL HA identified with reference numeral 420A in FIG. 4,the user network device 105A is linked via an encrypted HTML Internetchannel 140A to the biller address, i.e. URL address HA, at which thedetailed bill information of the biller A for user A is stored. Thedetailed bill information is then provided via the channel 140A to theuser A network device 105A without either the request or the provideddetailed bill information flowing through the service provider 120 oraccess portal 115.

It should be understood that, if the bill detail information were storedat the service provider 120 or an aggregator (not shown), the hyperlinkwould link directly to an address at the aggregator or service providernetwork site at which the requested detailed bill information ismaintained. In any event, the access portal 115 does not vouch for userA to biller A, the aggregator, or the service provider 120 in connectionwith the bill detail request and the bill detail information iscommunicated to the user A from biller A, the aggregator or the serviceprovider 120 without flowing through the access portal 115.

This lack of authentication by the access portal 115 in connection withthe bill detail request from user A is sometimes referred to as “theproblem of transitive authentication”. To address this problem it hasbeen proposed to implement an OFX protocol (i.e. Open Financial ExchangeSpecification 1.5.1 dated Nov. 23, 1995, www.OFX.net) such that thecreator of the bill detail information, e.g. the biller, aggregator orservice provider etc., create a somewhat extended URL.

As shown in FIG. 5A, in the proposed implementation of OFX 1.5.1, thesomewhat extended URL 500 includes a network address 505 for the billdetail information, a bill identification (ID) 510 which identifies theparticular bill being requested, and a user account number 515 which thebiller associates with the applicable user. As indicated in FIG. 5A, thebill ID and user account number are typically encrypted, but may insteadbe hashed.

FIG. 5B presents a more realistic depiction of the somewhat extended URL500 of FIG. 5A for a typical Internet address prior to encrypting orhashing the bill ID 510 and user account number 515. More particularly,FIG. 5B depicts the somewhat extended URL 500′ with the network address505′, the bill ID 510′ and the account number 515′.

The somewhat extended URL 500′ provides the recipient of the request fordetailed bill information, e.g. the biller, bill aggregator or serviceprovider, with sufficient information to identify the particular billbased on the bill ID 510′ and to verify the user account number based onaccount number 515′, prior to allowing access to the detailed billinformation stored at address 505′. However, the recipient has no way ofverifying that the request has actually been made by the appropriateuser, for example user A as shown in FIG. 3B. Furthermore, there is noway for the recipient to know whether the somewhat extended URLoriginally transmitted by the access portal 115 has been tampered withand, for example, includes modified e.g. mangled, address, bill IDand/or user account number information.

For example, it is impossible for the recipient to know if the somewhatextended URL has been improperly copied from the user's browser eitherby operation of the user's network device on which the somewhat extendedURL may be stored, by hacking into the information stored on the user'snetwork device by the browser, or by installing coding, such as a JAVAapplet, which automatically transmits information stored on the user'snetwork device without user's knowledge to a network device under thecontrol of others. It is also impossible for the recipient to know ifthe encrypted data has been altered. Hence, the proposed implementationof OFX 1.5.1 cannot ensure the integrity of the somewhat extended URL orserve as an aid in authenticating to the recipient that the requester iswho he/she says he/she is.

Accordingly, a need remains for a technique to address the problem oftransitive authentication.

SUMMARY DISCLOSURE OF THE INVENTION

In accordance with the invention a networked system for accessinginformation includes a first network station, such as a network serveror other network device, which represents a first network entity, forexample a biller. A second network station, which could be anothernetwork server or some other network device, represents a second networkentity, such as an access portal, and controls access to the network bya third network entity. The first station controls access toinformation, such as detailed bill or other information, stored on anetwork for the third network entity, such as a customer of the biller.The first station encrypts a first component message, sometimes simplyreferred to as a first component of an aggregate message, with a firstcrypto-key associated with the first network entity, e.g. the biller.

The first crypto-key could be a symmetric crypto-key which is known onlyto the first network entity. Alternatively, the first crypto-key couldbe a non-symmetric crypto-key, such as a public crypto-key of a jointprivate-public crypto-key pair associated with the first network entity.In any event, beneficially the first network station encrypts the firstcomponent message off-line, i.e. in non-real time. That is, preferablethe first network station encrypts the first component message at a timeother than the time of a request, such as a request for bill summaryinformation, which will be responded to by transmitting the encryptedfirst component message. The first component message preferably includesidentity information associated with the third network entity, andintegrity information which corresponds to the identity information. Theidentity information advantageously includes an identification ofinformation stored on the network, such as a bill ID and/or an accountnumber. The integrity information could, for example, include a hash ofthe identity information. In a typical implementation, the first networkstation combines the encrypted first component message with a networkaddress for the stored information.

The integrity information provides enhanced immutability, by ensuringthat the first network entity can verify that a returned first componentmessage has not been mangled or otherwise altered. For example, if thefirst component message includes a bill ID and payor account numberwhich is returned to the biller by the payor with the request fordetailed bill information, the biller can use the integrity informationto verify that the returned bill ID and account information are the samebill ID and account number included in the first component message.

The second network station encrypts a second component message with asecond crypto-key and combines the encrypted first and the encryptedsecond component messages. The combined messages are then transmittedover the network, which could for example be the Internet. It would berecognized by those skilled in the art that the second crypto-key could,if desired, also be applied to the encrypted first component message atthe time of encrypting the second component message.

The second crypto-key could be a non-symmetric crypto-key. Thenon-symmetric crypto key might, for example, be a private crypto-key ofa joint private-public crypto-key pair associated with the secondnetwork entity. Alternatively, the second crypto-key could be asymmetric crypto-key known also to the first network entity. In anyevent, preferably the second network station encrypts the secondcomponent message and combines the encrypted first and the encryptedsecond component messages on-line, i.e. in real time. That is, thesecond network station beneficially encrypts the second componentmessage and combines it with the encrypted first component message atthe time of a request, e.g. a bill summary request, which will beresponded to by transmitting the combine component messages.

The second component message preferably includes voucher informationwhich indicates that the second network entity has authenticated thethird network entity. The voucher information enhances authentication byallowing the second network entity to vouch for the third network entityto the first network entity. The voucher information can be used toauthenticate who the third network entity is and, if desired, the thirdnetwork entity's relationship with the second network entity. Thisallows, for example, a portal to confirm to a biller that the payorrequesting detailed bill information is who he/she says he/she is andthat the payor has a relationship with the portal.

Advantageously, the second component message also includes a timestampcorresponding to a time at which the combined messages are transmittedby the second network station. The timestamp enhances secrecy bypreventing a misappropriated combined messages from later, i.e. beyondsome designated time period after the time indicated by the timestamp,being used to access the information, such as detailed bill information.The timestamp also enhances non-repudiation, since it can be used by thefirst network entity to confirm that the combined messages were recentlytransmitted by the second network entity to the third network entity.Thus, for example, the timestamp can be used by a biller to confirm thata request for detailed bill information was received promptly after theassociated bill summary information had been provided by a portal to theapplicable payor.

A third network station, such as a personal computer or other networkdevice, represents the third network entity and receives the transmittedcombined messages, or what might also be referred to as an aggregatemessage formed of combined component messages. The third station furthertransmits the received combined messages over the network in order toobtain access to the stored information. In this regard, the firstnetwork station receives the further transmitted combined messages, anddecrypts the encrypted first and the encrypted second component messagescontained therein. The first network station then controls access by thethird network station to the stored information based on the decryptedfirst and second component messages. For example, if the first stationis unable to successfully decrypt either of the component messages,access would typically be denied. If the decrypted first componentmessage is associated with an entity different than the entity beingvouched for in the second component message access would also be denied.If the timestamp indicates that a threshold time period has expiredsince the second network station transmitted the combined message,access may be denied.

In accordance with other aspects of the invention, a fourth networkstation, such as another server or network device, represents a fourthnetwork entity, for example a service provider. The fourth networkdevice encrypts a third component message with a third crypto-key andinitially combines the encrypted first and third component messages. Thefourth network station then transmits the initially combined messagesover the network.

The third crypto-key could be a non-symmetric crypto-key, which, forexample, might be a private crypto-key of a joint private-publiccrypto-key pair associated with the fourth network entity.Alternatively, the third crypto-key could be a symmetric crypto-keyknown also to the first network entity. In any event, preferably thefourth network station encrypts the third component message and combinesthe encrypted first and the encrypted third component messages on-line,i.e. in real time. That is, the fourth network station advantageouslyencrypts the third component message and combines it with the firstcomponent message at the time of a request, e.g. a bill summary request,which will be responded to by transmitting the combined messages. Thepublic crypto-keys associated with the second and fourth networkentities, could be distributed by either one of these entities, or byeach of these entities, or by some other network entity.

The third component message preferably includes relationship informationwhich indicates that the identity and integrity information was receivedby the fourth network entity from the first network entity andtransmitted by the fourth network entity to the second network entity.

The second network station receives the transmitted initially combinedmessages, and combines the encrypted first and the encrypted thirdcomponent messages contained therein with the encrypted second componentmessage to create the above described combined messages. Hence, thefirst network station can decrypt the encrypted third component messageand also use this message to control access by the third network stationto the stored information. For example, if the information in the thirdcomponent message is inconsistent with that in the second componentmessage, access will be denied.

It should be understood that as used herein, the network could be madeup of multiple sub-networks, some of which could be public while othersare private. For example, in a bill presentment and paymentimplementation, the first and third network stations and the second andthird network stations might communicate over the Internet, while thefourth network station communicates with the first network station viathe Internet or some other network, and with the second network stationover the Internet or some still further network.

In accordance with other aspects of the invention, an electronic messagehas a first component created by a first network entity and encryptedwith a first crypto-key, associated with the first network entity, suchthat the encrypted first component can be decrypted by only the firstentity. The message also includes a second component created by a secondnetwork entity, and encrypted with a second crypto-key, such that theencrypted second component can also be decrypted by the first networkentity. In some implementations, the message may advantageouslyadditionally include a third component created by a third network entityand encrypted with a third crypto-key, associated with the third networkentity, such that the encrypted third component can be decrypted by thefirst network entity.

According to further aspects of the invention an electronic message,includes a first component encrypted with only a symmetric crypto-keyand a second component, different than the first component, encryptedwith only a non-symmetric crypto-key. In certain implementations thesymmetric crypto-key is associated with a first entity, and may only beknown to the first entity, while the non-symmetric crypto-key isassociated with a second entity. The non-symmetric crypto-key maybeneficially be a private crypto-key of a joint private-publiccrypto-key pair associated with the second entity.

In accordance with still other aspects of the invention, an extendednetwork universal resource locator (URL) which is particularly suitablefor Internet commerce includes a first component having a networkaddress at which stored information can be accessed on a network. Theextended URL also includes a second component having identityinformation associated with a first network entity and an integrityvalue corresponding to the identity information. The second component isencrypted with a first crypto-key of a second network entity. Theextended URL additionally includes a third component having relationshipinformation indicating that the encrypted second component was receivedby a third network entity from the second network entity and transmittedby the third network entity to a fourth network entity. The thirdcomponent is encrypted with a second crypto-key of the third networkentity. The extended URL further includes a fourth component havingvoucher information indicating that the fourth network entity hasauthenticated the first network entity and that transmission of theextended URL by the fourth network entity to the first network entityoccurred at a particular time. The fourth component is encrypted with athird crypto-key of the fourth network entity.

For example, if the extended universal resource locator is implementedin connection with electronic bill presentment via the Internet, thestored information could be detailed bill information. The networkaddress would be an Internet URL. The identity information could includean identification of the stored information, e.g. detailed billinformation and an account number associated with the first networkentity. Preferably, the integrity value is a hash of the identityinformation and the transmission time information is a timestamp.

In such an implementation, the second network entity might be a billeror other entity which controls access to the stored information, such asthe detailed bill information. The third network entity, might be aservice provider, such as CheckFree Corporation, which controls accessto other information, such a summary bill information, which istransmitted with the extended network universal resource locator by thefourth network entity to the first network entity, which might be thecustomer. The fourth network entity might an access portal whichcontrols access by the first network entity to other entities on thenetwork.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 depicts a conventional bill presentment network.

FIG. 2 depicts the user identification information conventionallyavailable to the access portal and the billers of FIG. 1.

FIG. 3A depicts a typical message flows between a user, the accessportal, the service provider and a biller to request and present billsummary information via the FIG. 1 network.

FIG. 3B depicts a typical message flows between and a user and a billerto request and present detailed bill information via the FIG. 1 network.

FIG. 4 depicts a conventional presentation of bill summary informationto the user shown in FIG. 3A.

FIG. 5A depicts a conventional URL for use by the user shown in FIG. 3Bin requesting detailed bill information.

FIG. 5B is a more realistic depiction of the URL of FIG. 5A.

FIG. 6 depicts message flows between a user, the access portal, theservice provider and a biller to request and present bill summaryinformation via the FIG. 1 network in accordance with the presentinvention.

FIG. 7 depicts a portion of the collaboratively manufactured extendedURL for use in requesting detailed bill information as shown in FIG. 6,in accordance with the present invention.

FIG. 8 depicts another portion of the collaboratively manufacturedextended URL for use in requesting detailed bill information as shown inFIG. 6, in accordance with the present invention.

FIG. 9 depicts a combination of summary bill information and theportions of the collaboratively manufactured extended URL shown in FIGS.7 and 8, in accordance with the present invention.

FIG. 10 depicts still another portion of the collaborativelymanufactured extended URL for use in requesting detailed billinformation as shown in FIG. 6, in accordance with the presentinvention.

FIG. 11 depicts a combination of summary bill information and thecollaboratively manufactured extended URL, in accordance with thepresent invention.

BEST MODE FOR CARRYING OUT THE INVENTION

Although the present invention will now be described in the context ofbill presentment, it should be recognized that the invention has wideapplicability and can be easily adapted for use in obtaining virtuallyany type of private information by a user directly from the custodian ofthat information. For example, the present invention may havesignificant application in web banking, web brokerage, web mortgaging,request for credit reports, etc. without requiring the user to sign-onwith other than its access portal during the session, even though theuser will access the information directly from an entity other that theaccess portal during the session.

FIG. 6 depicts typical communications between and functions of variousnetwork entities in providing bill summary information to a requestinguser with a collaboratively manufactured extended URL. As shown, andpreviously described with reference to FIG. 3A, network device 105Arepresenting user A implements a browser 305 to communicate itscredentials via an encrypted HTML communication over the Internetchannel 125A to the access portal 115. The access portal 115 processesthe credentials to authenticate user A as indicated by reference numeral310, and provides a response, as represented by the communicatedauthentication message, to network device 105A either granting ordenying access based on whether or not User A has been successfullyauthenticated by the processing of the credentials. If access isgranted, user A, operating network device 105A, can now request billsummary information from the access portal 115 via the channel 125A.

Having authenticated user A, the access portal 115 transmits the requestvia a protocol over channel 130 to the service provider 120. Asdescribed above with reference to FIG. 5A, in accordance with OFX 1.5.1the URL 500 conventionally provided to the service provider 120 from thebiller includes a network address (NA) for the bill detail information505, a bill ID (BID) 510 which identifies a particular bill beingrequested and the account number (AN) 515 which the biller associateswith the applicable user.

As shown in FIG. 7, in accordance with the present invention, the billerperforms a hash computation, H, on the network address (NA) 505 for thebill detail information, the bill ID (BID) 510 which identifies aparticular bill being requested and the account number (AN) 515 whichthe biller associates with the applicable user to form an integrityvalue (IV) 520 as follows:H[NA+BID+AN]  (1)

The bill ID 510, user account number 515 and the integrity value 520 arethen encrypted using a symmetric encryption key E to form an encryptedmessage as follows:NA+E[BID+AN+IV]  (2)

It should be understood that, if desired, the encryption could beperformed using the biller's non-symmetric public key of a jointprivate/public key pair, in lieu of the symmetric key E. In either case,the encryption and integrity value ensure the integrity of the basedata, i.e. the bill ID 510 and the user account number 515, and theidentification of the applicable user, in this case user A. Theencrypted integrity value provides enhanced protection against alteringof the information which will be returned to the biller by the payorwith the request for detailed bill information. Hence, the biller can beconfident that the exact bill ID, account information and useridentification sent to the user is returned with user's the request fordetailed bill information.

As also shown in FIG. 7, in accordance with the present invention, theencrypted bill ID 510, user account number 515 and integrity value 520are also signed using a digital certificate S(1), preferably supplied bythe service provider 120 but which could alternatively be supplied by aseparate certificate authority, to form an encrypted, signed extendedURL message 700 to the detailed bill information as follows:NA+[E[BID+AN+IV]]S(1)  (3)

The bill summary information (BSI) and the encrypted, signed extendedURL message 700 are provided by each biller A-C, preferably via a secureprotocol or batch communication over channels 135A-135C, to the serviceprovider 120 in a message 315 as the following:BSI+NA+[E[BID+AN+IV]]S(1)  (4)

Hence, responsive to the request from the access portal 115, the serviceprovider 120 can retrieve, for example from a local memory, theapplicable message(s) 315.

Continuing with the collaborative manufacture of the extended URL whichwill ultimately be returned to the user requesting the bill information,the service provider 120 creates, either prior to, i.e, off-line, or atthe time of the request for the bill summary information, i.e. on-line,an encrypted, signed relationship certification (RC) 800, as shown inFIG. 8. The relationship certificate includes a certification 810 thatthe service provider 120 received each of the applicable encrypted,signed extended URL messages 700 from the applicable biller A-C and acertification 820 that the service provider 120 is delivering theapplicable encrypted, signed extended URL messages 700 to the accessportal 115. The access portal 115 may, for example under the OFXprotocol, be identified to the service provider 120 in the request forbill summary information received by the service provider 120 from theaccess portal 115.

As shown in FIG. 8, the relationship certificate is encrypted, using theservice provider's 120 non-symmetric private key, PKSP(2), of its jointprivate key PKSP (2)/public key PUBKSP(2) pair, and digitally signedusing the service provider's 120 digital certificate S(2). Thus theencrypted, signed relationship certificate will take the form of amessage such as the following:[[RC]PKSP(2)]S(2)  (5)

The encrypted relationship certificate will ensure that the commercialparties, i.e. the service provider 120 and the access portal 115, areidentified in the extended URL.

As shown in FIG. 9, the bill summary information 910 and a furtherextended URL message, including the encrypted, signed extended URLmessage 700 and the encrypted, signed relationship certificate 800, aretransmitted over channel 130 from the service provider 120 to the accessportal 115 in a further extended message 900 in the following form:BSI+NA+[E[BID+AN+IV]]S(1)+[[RC]PKSP(2)]S(2)  (6)

It should be recognized that the message 900 may be created and storedby the service provider 120 prior to receiving a request for the billsummary information or created in response to the receipt of such arequest.

After receipt of message 900, the access portal 115 may, if desiredverify that message 900 is from the service provider 120 and intendedfor the access portal 115 by applying the public key PUBKSP(2) ofservice provider 120 to the encrypted relationship certificate asfollows:[PKSP(2)]PUBKSP(2)  (7)

The access portal 115 continues the collaborative manufacture of thestill further extended URL which will ultimately be returned to the userrequesting the bill information. In this regard, the access portal 115creates a voucher (V) 1005, depicted in FIG. 10, which identifies theaccess portal 115 and indicates that the access portal 115 hasauthenticated the user, in this case user A.

The access portal 115 then encrypts, using the access portal's 115non-symmetric private key, PKAP(3), of its joint private keyPKAP(3)/public key PUBKAP(3) pair, and signs, using a digitalcertificate, S(3), provided by the service provider 120 or some othercertificate authority, the voucher (V) 1005 and a time stamp (TS) 1010to form an encrypted, signed voucher record (VR) 1000 as follows:[[V+TS]PKAP(3)]S(3)  (8)

The encrypted, signed voucher will ensure that it can be verified thatthe applicable user is known to the access portal 115, and theencrypted, signed timestamp will ensure that the bill detail request hasonly a limited lifetime.

More particularly, the voucher enhances authentication. That is, thevoucher, which will be transmitted by the portal to the user with thebill summary information and by the user to the biller with the requestfor detailed bill information as will be described further below, servesas the portal's confirmation to the biller that the payor is in fact whohe/she says he/she is and that the payor has a relationship with theportal.

The timestamp enhances secrecy and non-repudiation by preventing thenetwork address 505 in the collaboratively manufacture extended URL 1150from being used to access the user's detailed bill information after ashort timeout, i.e. threshold, period, e.g. 30 minutes from thetransmission of the extended URL 1150 by the portal. Although notfoolproof, since the timestamp prevents a misappropriated networkaddress 505 from being used to access detailed bill information after arelatively short period of time, the likelihood that a request to accessdetailed bill information from some misappropriating party will begranted, is significantly reduced. Furthermore, because the timestampevidences that the bill summary information associated with the nowrequested detailed bill information was recently, i.e. within thetimeout period, transmitted to the user by the portal, it is moredifficult for the user to repudiate its receipt of the bill summaryinformation and/or of its request for access to the detailed billinformation.

The bill summary information and the still further extended URL 1150,including the encrypted, signed extended URL message 700, the encrypted,signed relationship certification 800, and the encrypted, signed voucherrecord 1000, are transmitted as the following message, depicted asmessage 1100 in FIG. 11, over encrypted html channel 130, from theaccess portal 115 to the requesting user, here user A being representedby network device 105A:BSI+NA+[E[BID+AN+IV]]S(1)+[[RC]PKSP(2)]S(2)+[[VR]PKAP(3)]S(3)   (9)

It will be recognized that encrypted html channels are often referred toas https or secure socket layer (SSL) channels.

Accordingly, the access portal 115 directs to the user network device105A, via the channel 125A in an encrypted HTML message, a message 1100having a very rich, collaboratively manufactured extended URL 1150including:

(i) the encrypted, signed extended URL message 700 generated by thebiller with the unencrypted network address, NA, 505 at which the billdetail information is stored and the encrypted, signed billidentification, BID, 510, user account number, AN, 515, and integrityvalue, IV, 520,

(ii) the encrypted, signed relationship certification, RC, 800 generatedby the service provider 120 which certifies that the encrypted signedextended URL message 700 was received from the applicable biller A-C anddelivered to the applicable access portal 115, and

(iii) the encrypted, signed voucher record, VR, 1000 generated by theaccess portal with the voucher 1005 certifying that the access portal115 has provided the collaboratively manufactured extended message 1100to the applicable user, in this case user A, and the time stamp 1010.

With the collaboratively manufactured extended URL 1150 of message 1100,as shown in FIG. 11, substituted for the URL 500 shown in FIG. 5, thedisplay 400 of Internet device 105A presents, as shown in FIG. 4, therequested bill summary for user A. The presented bill summary includes aview bill request area associated with each of the billers A-C indisplay areas 415A-C. The view bill request area can be clicked on usinga mouse or other input device to activate the applicable collaborativelymanufactured extended URL 1150 forwarded in message 1100 to hyperlink tothe bill detail information underlying the applicable bill summaryinformation being presented, as previously described with reference toFIG. 3B. Thus, by clicking on view bill area 415A and thereby activatingthe collaboratively manufactured extended URL 1150 to the bill detailfor biller A's bill, the user network device 105A is linked via anencrypted HTML channel 140A to the address at which the detailed billinformation of the biller A for user A is stored as described withreference to FIG. 3B.

However, before the detailed bill information is provided via thechannel 140A to the user A network device 105 A, the biller checks thesignature S(1) on the encrypted bill ID 510, user account number 515 andintegrity value 520, and decrypts, using the corresponding symmetricdecryption key D or the billers non-symmetric private key, asapplicable, the bill ID 510, user account number 515 and integrity value520 as follows:D[BID+AN+IV]  (10)

The biller verifies the decrypted bill ID 510 and user account number515 and, using the integrity value 520, also verifies that thisinformation was the same information which it originally forwarded tothe service provider 120.

Further, the biller checks the signature and then decrypts the encryptedrelationship certificate using the public key, PUBKSP(2), of the serviceprovider 120 as follows:[[RC]PKSP(2)]PUBKSP(2)  (11)

The biller, using the relationship certificate, verifies that theservice provider 120 received the bill ID 510, user account number 515and integrity value 520 from the applicable biller and forwarded thisinformation to the access portal 115.

Further still, the biller checks the signature and then decrypts theencrypted voucher record using the public key, PUBKAP(3) of the accessportal 115 as follows:[[VR]PKAP(3)]PUBKAP(3)  (12)

The biller, using the voucher record, verifies that the access portal115 identified in the relationship statement of the service provider 120vouches for the applicable user, and that, based on the time stamp, thetime period within which the request for detailed bill information hasbeen received is within a designated threshold, preferably two to fiveminutes.

Hence, not only is bill summary information transmitted via a secureprotocol from the biller to the service provider and from the serviceprovider to the access portal, but the bill summary information is nottransmitted until after the applicable user is authenticated by theaccess portal. Further, the bill summary information for a particularuser is provided to the access portal for transmission to the requestinguser only if the access portal 115 can vouch for the user to the serviceprovider 120 based upon its authentication of the user. Moreover, thecollaboratively manufactured extended URL 1150 provides the requestrecipient, e.g. the biller, bill aggregator or service provider etc.,information necessary to identify the particular bill and verify theuser account number prior to allowing access to the detailed billinformation.

Additionally, using the above described technique, the recipient now hasa way of verifying that the request has actually been made by theappropriate user, for example user A as shown in FIG. 6. Moreparticularly, the collaboratively manufactured extended URL 1150provides the recipient with the ability to verify that the informationoriginally transmitted by the access portal has not been tampered withand hence, reflects the correct network address, bill ID and useraccount number information. Further, the collaboratively manufacturedextended URL 1150 makes it possible for the recipient to determine ifthe information has been improperly copied from user A's browser. Hence,by collaborative manufacture the integrity of the information andauthenticity of the requesting party can be ensured.

As described above, the present invention addresses the problem oftransitive authentication. Further, the present invention provides atechnique which protects the integrity of the URL's which are used toaccess private information over a network. Additionally, the presentinvention provides a technique which allows a URL to be utilized by arequest recipient to authenticate the requesting party.

It will also be recognized by those skilled in the art that, while theinvention has been described above in terms of one or more preferredembodiments, it is not limited thereto. Various features and aspects ofthe above described invention may be used individually or jointly.Further, although the invention has been described in the context of itsimplementation in a particular environment and for particular purposes,e.g. creating extended URL's, those skilled in the art will recognizethat its usefulness is not limited thereto and that the presentinvention can be beneficially utilized in any number of environments andimplementations. Accordingly, the claims set forth below should beconstrued in view of the full breadth and spirit of the invention asdisclosed herein.

1. A method comprising: receiving, from a network entity that controlsaccess to stored information associated with a user, by a serviceprovider, a network address associated with the stored information and afirst message component, wherein the first message component isencrypted with a first crypto-key associated with the network entity andcan be decrypted by the network entity, wherein the first messagecomponent includes user identity information and integrity information,wherein the user identity information is associated with the storedinformation and the integrity information is associated with the useridentity information; receiving, from an access portal associated withthe user, by the service provider, a request for information enablingaccess to the stored information; responsive to the request, generating,by the service provider, a response, wherein the response includes thenetwork address and the first message component; and transmitting, tothe access portal, by the service provider, the generated response,wherein the response is extensible by the access portal to include asecond message component and a third message component, wherein thesecond message component is encrypted with a second crypto-keyassociated with the access portal, and wherein the extended response isusable to obtain access to the stored information; wherein the thirdmessage component is encrypted with a third crypto-key associated withthe service provider, and wherein the third crypto-key can be decryptedby the network entity that controls access to the stored informationassociated with the user; wherein content of the third message componentincludes first relationship information indicative of a relationshipbetween the service provider and the network entity, wherein the firstrelationship information indicates that the user identity informationand the integrity information were received by the service provider fromthe network entity; and wherein the content of the third messagecomponent includes second relationship information indicative of arelationship between the service provider and the access portal, whereinthe second relationship information indicates that the user identityinformation and the integrity information were transmitted by theservice provider to the access portal.
 2. The method of claim 1, whereinthe access portal and the service provider are supported by differentnetwork stations.
 3. The method of claim 1, further comprises:receiving, from the network entity, summary data associated with thestored information; and wherein the response includes summaryinformation associated with the summary data, and wherein the summaryinformation is configurable to be presented to the user associated withthe access portal.
 4. The method of claim 1, wherein the network entityis a biller.
 5. The method of claim 1, wherein the network addressassociated with the stored information is the network address of thenetwork entity.
 6. The method according to claim 1, wherein the firstcrypto-key is a symmetric crypto-key.
 7. The method according to claim6, wherein the symmetric crypto-key is known only to the network entity.8. The method according to claim 1, wherein the first message componentfurther includes an identifier associated with the stored information.9. The method according to claim 1, wherein the integrity informationincludes a hash of the user identity information.
 10. The methodaccording to claim 1, wherein the first message component includes adigital signature.
 11. The method according to claim 1, wherein thesecond message component can be decrypted by the network entity.
 12. Themethod according to claim 1, wherein the second crypto-key is a privatecrypto-key of a joint private-public crypto-key pair associated with theaccess portal.
 13. The method according to claim 1, wherein the secondmessage component includes voucher information, wherein the voucherinformation indicates that the access portal has authenticated the user.14. The method according to claim 1, wherein the second messagecomponent includes a digital signature.
 15. The method according toclaim 1, wherein the second message component includes a timestampcorresponding to a time at which the summary information is transmittedto the user by the access portal.
 16. The method according to claim 1,wherein the third crypto-key is a private crypto-key of a jointprivate-public crypto-key pair associated with the service provider. 17.The method according to claim 1, wherein the third message componentincludes a digital signature.
 18. A system comprising: a memory, whereinthe memory is operable to locally store data received from a remotelylocated network entity; an interface capable of communicating with anaccess portal and the network entity; and a processor, wherein theprocessor is configured to: receive, from the network entity, a firstmessage component and a network address associated with the networkentity, wherein the first message component is encrypted with a firstcrypto-key associated with the network entity and can be decrypted bythe network entity, wherein the first message component includes useridentity information and integrity information, receive, from an accessportal, a request for information enabling access to remotely storeddata associated with the network entity, responsive to the request,responsive to the request, generate a response, wherein the responseincludes the network address and the first message component, andtransmit, to the access portal, the response, wherein the response isextensible by the access portal to include a second message componentand a third message component, wherein the second message component isencrypted with a second crypto-key associated with the access portal,and wherein the response is usable to obtain access to the storedinformation, wherein the third message component is encrypted with athird crypto-key associated with the service provider, wherein the thirdcrypto-key can be decrypted by the network entity, wherein content ofthe generated third message component includes first relationshipinformation indicative of a relationship between the service providerand the network entity, wherein the first relationship informationindicates that the user identity information and the integrityinformation were received by the service provider from the networkentity, and wherein the content of the generated third message componentincludes second relationship information indicative of a relationshipbetween the service provider and the access portal, wherein the secondrelationship information indicates that the user identity informationand the integrity information were transmitted by the service providerto the access portal.
 19. The system according to claim 18, wherein theprocessor is further configured to receive summary data from the networkentity and to direct the storage of the received summary data and thefirst message component to the memory.
 20. The system according to claim18, wherein the third crypto-key is a private crypto-key of a jointprivate-public crypto-key pair associated with the service provider. 21.The system according to claim 18, wherein the third message componentincludes a digital signature.